A distributed application execution system may be used to develop and host large numbers of computer applications, with each application having its own set of fluctuating resource requirements. Such a system may contain an application master and a plurality of application servers. Computer applications running in the application execution system may be sandboxed and executed across multiple application servers in several data centers.
FIG. 1 is a block diagram of a distributed computing system 100 including an application execution system 130 connected to a plurality of clients 102 (e.g. 102-1 . . . 102-n) through a network 110 such as the Internet, other wide area networks, local area networks, metropolitan area networks, wireless networks, or any combination of such networks. In some embodiments, a respective client 102 contains one or more client applications 104 (e.g. 104-1 . . . 104-n), such as a web browser, for submitting application execution requests to the application execution system 130. The client 102 (sometimes called the “client device” or “client computer”) may be any computer or similar device through which a user of the client 102 can submit requests to and receive results or services from the application execution system 130. Examples of a client device 102 include, without limitation, desktop computers, notebook computers, tablet computers, mobile devices such as mobile phones, personal digital assistants, set-top boxes, or any combination of the above.
In some embodiments, the application execution system 130 includes one or more front-end servers 140. The front-end sever 140 receives application execution requests from clients 102 and returns results to the requesting clients.
The application execution system 130 also includes a plurality of application servers 160 (e.g., 160-1 through 160-n). Each of the application servers 160 includes volatile storage 164 for executing one or more applications, non-volatile storage 166 for storing one or more applications, and computational resources 168 for executing applications in response to requests received by the application execution system 130.
In some embodiments, the application execution system 130 also includes an application master 150 that distributes applications, from a main library 152 having a plurality of applications, among the application servers 160. In the embodiment shown in FIG. 1, the main library 152 is stored in the application master 150. In some embodiments, each application of the plurality of applications in the main library 152 is a web application that is responsive to HTTP requests. However, the present invention can also be used in non-web based environments, in which case the applications need not be web-based applications.
In other embodiments, the application execution system 130 includes a data store 180 that is accessible to each of the application servers 160, which includes information about which application servers accept service requests for a particular application.
A distributed application execution system may be used for developing and hosting computer applications in data centers across the world. The application execution system may automatically scale a computer application as the number of requests increases for the application. Scaling may include allocating more resources for a computer application when the application experiences an increase in requests.
Furthermore, the system may provide access to application programming interfaces (APIs) that are only available to the computer applications that exist within the application execution system. An API is a code-based specification that allows software components to communicate with one another. APIs may contain information such as the methods available and the data returned by the available methods from a particular web service.
A customary distributed application execution system may provide computer applications with an API for queuing tasks. A task may be defined as a small amount of work and may consist of two parts: (1) a data payload which parameterizes the task and (2) the code which implements the task. Tasks may be added to a queue in order for the tasks to be processed in the background of a computer application. Using a task queue, computer applications can define tasks, add them to a queue, and process the tasks in aggregate and in non-real-time. In a customary distributed application execution system, a task queue may be one of several types including a push queue or a pull queue.
A push queue pushes work to workers in a computer application when tasks are available for that application. The work is processed by the distributed application execution system's infrastructure which automatically scales the computer application which has tasks to do.
In contrast, pull queues allow a task consumer to lease tasks at a specific time for processing within a specific time period. The task is locked to the task consumer for the time period of the lease. The task consumer tries to process and delete tasks before the lease ends. If the task consumer does not complete the task in the allotted time period, the task is made available for other task consumers to lease. The task can be leased a configurable amount of times before the task is deleted from the queue without being processed.
Computer applications within an application execution system are considered internal applications whereas computer applications that are not in the application execution system are considered external computer applications. In some instances, internal computer applications may need to perform work received from external computer applications. To perform the work, an internal computer application needs to be notified about the work and assigned tasks to complete the work.
Conventional processes notify internal computer applications in real-time about tasks which causes the internal computer applications to act on the tasks as they are received. This immediate reaction to tasks can interfere with the internal computer application's behavior because resources may have to be dedicated to responding to the tasks. To avoid interference with an internal computer application's real-time behavior, there should be an external notification and tasking process that allows an internal computer application to receive external tasks in non-real-time. As recognized by the inventors, tasks from external systems should be sent to an internal computer application using a mechanism that allows the internal application to act upon the tasks at a convenient, non-busy time for the application.